Many enterprise data processing systems rely on multi-node database servers to store and manage data. Such enterprise data processing systems typically follow a multi-tier model that has a multi-node database server in the first tier, and one or more computers in the middle tier and outer tiers.
FIG. 1 depicts multi-node database server mds11, which is implemented on multi-tier architecture 10. A server, such as multi-node database server mds11, is a combination of integrated software components and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients. Resources from multiple nodes in a multi-node computer system can be allocated to run a particular server's software. A particular combination of the software on a node and the allocation of the resources from the node is a server that is referred to herein as a server instance or instance. Thus, a multi-node server comprises multiple server instances that can run on multiple nodes. Several instances of a multi-node server can even run on the same node.
A database server governs and facilitates access to a particular database, processing requests by clients to access the database. A multi-node database server, such as multi-node database server mds11, comprises multiple “database instances”, each database instance running on a node. Multi-node database server mds11 governs access to database db11. A multi-node database server can govern and facilitate access to one or more databases.
The middle-tier of multi-tier architecture 10 includes middle-tier computer cmp11 and the outer-tier includes user computer cmp12. User computer cmp12 executes browser br11, which interacts with an end-user. The end-user's interaction with browser br11 causes the browser to transmit requests over a network, such as the Internet, to middle-tier computer cmp11. The request causes a process client cl11 on middle-tier computer cmp11 to execute application appl11. Execution of application appl11 by the client cl11 causes client cl11 to connect to multi-node database server mds11. For example, application appl11 may be an order entry application that is configured to receive order requests from browser br11. Data for the order entry application is stored in db11. To process the requests, execution of application appl11 by client cl11 causes client cl11 to connect to database db11. Once connected, client cl11 issues database statements to retrieve and manipulate data stored in database db11.
The tier that directly connects to a server, relative to other tiers in a multi-tier architecture, is referred to herein as containing the client of the server. Thus, client process cl11 is referred to herein as the client of multi-node database server mds11.
An application, as the term is used herein, is a unit of software that is configured to interact with and use the functions of a server. In general, applications are comprised of integrated functions and software modules (e.g. programs comprised of machine executable code or interpretable code, dynamically linked libraries) that perform a set of related functions.
An application, such application appl11, interacts with a multi-node database server mds11 via client-side interface component intcomp11. Execution of application appl11 by client cl11 causes client cl11 to execute client-side interface component intcomp11 to interact with multi-node database server mds11. Application appl11 includes invocations of routines (e.g. functions, procedures, object methods, remote procedures) of client-side interface component intcomp11. Applications are typically developed by vendors and development teams different from those that develop servers and interfaces to servers, such as multi-node database server mds11 and client-side interface component intcomp11.
In order for a client to interact with multi-node database server mds11, a session is established for the client on a database instance of multi-node database server mds11. A session, such as a database session, is a particular connection established for a client to a server, such as a database instance, through which the client issues a series of requests (e.g., requests for execution of database statements).
For each database session established on a database instance, session state is maintained for the session. Session state includes the data stored for a database session for the duration of the database session. Such data includes, for example, the identity of the client for which the session is established, and temporary variable values generated by processes and database components executing software within the database session. A database component is a set of software modules that provide specialized and related functions for a database server, and shall be described later in greater detail. An example of a database component is a Java execution engine.
The beginning and end of a session demarcates a unit of work. Often, the beginning of a database session corresponds to an end-user establishing an interactive session with an application via, for example, a browser, and ends when the end-user logs off. Thus, the beginning and ending of the database session depend on application logic and end-user action, and may not be controlled by a server on which the session is established.
Client-Side Interface Components
Client-side interface components, such as client-side interface component intcomp11, are software components that reside and are executed on the same computer of a client of a server, and that are configured to provide an interface between the client and the server. The client-side interface component intcomp11 is configured for performing the detailed operations needed to interface with multi-node database server mds11. For example, an application appl11 invokes a function of client-side interface component intcomp11 to establish a connection to multi-node database server mds11. The client-side interface component then handles the details of a connection on a particular instance of multi-node database server mds11. To make requests of multi-node database server mds11, such as a request for execution of a query, application appl11 is configured to invoke functions of client-side interface component intcomp11, which then transmits a request for the same to the node and database instance on which the session is established.
Client-side interface component intcomp11 may generate and/or access state that is hidden from other software modules, that is, is not or may not be referenced and accessed by other software modules, and in particular, by application appl11. Such state is referred to as being internal or private to client-side interface component intcomp11.
For example, to create a database session on a multi-node database server mds11, application appl11 invokes a routine of client-side interface component intcomp11. The client-side interface component establishes a database session on a particular database instance within multi-node database server mds11, and stores details about the database session within internal data structures or objects. Such data structures and objects define, for example, the session established for an application, and specify such values as a session id that identifies a session on a database instance, the name of the database instance, and a network address and port number for the connection to the database instance.
Such details of the session are not returned to application appl11, nor may application appl11 access the details. Instead, what is provided to application appl11 is an “external identifier” for the session, such as a value that internal data of client-side interface component intcomp11 maps to the session, or a reference to an object generated by client-side interface component intcomp11 to store some details of the session in private attributes of the object that are inaccessible to application appl11. In this way, application appl11 does not “know” of the specific details of the session that has been established for it; however, application appl11 has the information needed to be able to identify to client-side interface component intcomp11 the particular session that has been established for application appl11. Note that a session id that is internal to a client-side interface component relative to an application that uses the interface is referred to herein as an internal session id.
Calls
A call is a request made by a client to a server to execute a task. Typically, a call is made by a process executing an invocation of a routine in a software module. The invocation causes the process to execute the routine (such execution may itself entail calling and executing other routines), and then to return to execute the module to a point at or just beyond the invocation (or some other designated point e.g. exception handler).
A call causes the calling process or remote process to execute the called routine, which may cause calling and execution of other routines. The call terminates when the call returns. Operations, which are carried out as part of execution of a called routine, are referred as being made within the call.
For example, to make a call to multi-node database server mds11, application appl11 makes a call of a function of client-side interface component intcomp11. In response to the invocation, client-side interface component intcomp11 executes the call, which entails client-side interface component intcomp11 modifying and accessing “local” data stored in the memory of client computer cmp12 by client-side interface component intcomp11, and client-side interface component intcomp11 making multiple remote procedure calls to a database instance within multi-node database server mds11, the multiple remote procedure calls including a first remote procedure call and a second remote procedure call. In response to the first remote procedure call, the database instance performs various operations. The modification and access of the local data, the multiple remote procedure calls, and the various operations performed by the database instance, are referred to as being performed within the “application call” made by application appl11. The various operations performed by the database instance while executing the routine invoked by the first remote procedure call (which may entail execution of other routines) are referred to herein as being made within the first remote procedure call, within a client-side call because the first remote procedure call was made by the client-side interface component intcomp11, and within an application call because the remote procedure call was made by client-side interface component intcomp11 while executing a routine called by application appl11. An application call or client-side call may both be referred to herein as a client call.
Sessions Often not in-Use
Sessions are used by applications to execute application calls. Most application actions, which include application calls, are made in response to end-user activity. End-user activity can occur in bursts, resulting in periods of inactivity between the bursts. During these periods of inactivity, the sessions are not being used by the application for which they were established.
Sessions, even sessions not in current use, consume resources of a database server. At a given moment, significant portions of a database server's resources are allocated to sessions that are not currently being used by the application.
It is possible to de-allocate resources allocated to a session by terminating the session. However, session state, being treated as transient state by a database server, is not preserved by the database server after termination of the session. Therefore, a session established for an application cannot be terminated until the application no longer needs the session state. The inability to preserve session state after termination impairs important database server capabilities.
Debugging Capability is Impaired
An important capability is providing information about transient session state for purposes of debugging. When debugging, it is useful to know the session state that exists when a bug occurs or to simulate running the software under the same or similar session state under which the bug occurs. Because session state of a session cannot be preserved, such information is not available to those debugging a bug nor may software be easily run under the same or similar session state.
Often, debugging requires the expertise of a database server vendor's experts or other outside experts. Because session state of a session cannot be preserved, this information cannot be kept for later examination by the experts or even transported to the expert's location where the expert could examine the session state and/or simulate the bug.
Applications and End-Users Unable to Terminate Sessions to Conserve Resources
When a database session is not in use depends largely on client-side behavior, and, in particular, the behavior of applications and end-users. Applications and the end-users may know what sessions are not in use. However, an application and end-user cannot request that such sessions be terminated to conserver resources because the sessions' state may be needed later—there is no capability that allows an application or end-user to request to terminate a session and preserve its state in a way that allows the session to be restored and continued when later needed.
Based on the foregoing, it is clearly desirable to provide approaches to terminate a session on an instance and preserve the session's state in a way that allows the session to be later resumed on the instance or a different instance, particularly in response to a request of an application or end-user to do so.